This picks up @dario-piotrowicz' work in #11323 and adds the things discussed in #11323 (comment).

It allows an adapter to provide an emulate function that returns a set of functions for influencing the dev and preview servers. Right now, there's only a platform function, which populates event.platform. This is useful for providing access to e.g. KV namespaces in development.

TODO:

• docs
• tests
• adapter-cloudflare-workers should also populate platform.context and platform.caches, I think? feat: implement adapter.emulate #11732
• do we need a cleanup mechanism? (e.g. bindings has a dispose method that is never called; we just kill the process. maybe that's fine?) if so what would it look like? not immediately necessary

Future:

• in SvelteKit 3.0, maybe emulate and platform should be mandatory for adapters that populate platform in production? Though it wouldn't allow us to remove the ? in platform?: App.Platform, since it's still not populated during prerendering (unless we decide otherwise?)
• Add other things besides platform, for e.g. adding platform-specific globals/modules, banning certain imports, special platform-specific routes (/_vercel for image optimisation), etc
• Provide a mechanism for telling SvelteKit which files should result in a dev server restart (e.g. in the Cloudflare case, you probably want to restart the dev server if you edit wrangler.toml)
• we have a bug in the types, albeit fairly harmless — because ValidatedKitConfig = RecursiveRequired<KitConfig>, TypeScript thinks adapter.emulate is always present. Not sure how to correct that
• add similar things for other adapters, where appropriate

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.